…ssues

Second review pass:
- Managed Supabase Database Webhooks wrap pg_net, whose http_post has no retry
  (supabase/pg_net#110 open), so they do NOT provide at-least-once delivery
  either. Remove the "built-in retry / recommended for durability" claim; frame
  the managed webhook as dashboard convenience only, and point durability at the
  recovery path / a transactional outbox.
- Update outstanding-issues #25 to match the corrected runbook: the trigger
  lands via committed migration (+ schema.sql + drift manifest); only the Vault
  secret + GUC are operator-applied. Prevents the durable-memory row from
  steering an operator back into the live-only drift gap.

Docs-only.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BHMgBiXbH4Q5tUC7WxoyaX

Review verified: the scheduled Ingestion Autopilot's assessIngestionHealth only
flags failed / stale-processing jobs — it never inspects `queued` documents with
no ingestion_jobs row, so it does NOT recover a dropped-webhook insert (even with
INGESTION_AUTOPILOT_APPLY=true). hasIncompleteDocumentsWithoutOpenJobs — the
predicate that would catch it — is wired only into the manual scripts/reindex.ts
CLI. So a dropped delivery for an outside-app insert has no automatic recovery.

Reframe the durability guidance accordingly: for a document that must never be
dropped, ingest via the app upload path (transactional enqueue) or add a
transactional outbox / scheduled queued-without-job sweep; the trigger and any
managed webhook are latency optimisations, not delivery guarantees. Align the
managed-alternative note and outstanding-issues #25.

Docs-only.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BHMgBiXbH4Q5tUC7WxoyaX

Verified in src/app/api/upload/route.ts: the upload route inserts the document
(status queued) then its own ingestion job, and on ANY job-insert error —
including a 23505 from the one-open-job-per-document unique index — it DELETES
the document and throws. A webhook trigger firing on INSERT could enqueue first,
making the upload's own job insert conflict and turning a normal upload into an
intermittent failure.

Fix the runbook: the trigger is now AFTER UPDATE on the reindex_requested flip
only (INSERT branch removed), so it never races the upload flow. Documents
inserted outside the upload path set metadata.reindex_requested = true to be
enqueued. Also warn that a managed Database Webhook must be scoped to UPDATE for
the same reason, and align the receiver-policy note + outstanding-issues #25.

Docs-only.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BHMgBiXbH4Q5tUC7WxoyaX

Two more review catches, both verified against the code:

- hasIncompleteDocumentsWithoutOpenJobs requires queuedDocuments === 0
  (src/lib/reindex-pipeline.ts), and scripts/reindex.ts only errors on it — so
  neither the autopilot nor the manual CLI recovers a stranded queued-without-job
  row. Drop the "manual reindex CLI is the backstop" claim: there is NO built-in
  recovery. To recover a stranded row, flip reindex_requested (fires the trigger);
  for guaranteed delivery use the app upload path or build a queued-without-job
  sweep.
- The trigger is AFTER UPDATE with a not-true -> true predicate, so an INSERT with
  reindex_requested already set never fires it. Document the required insert-then-
  separate-UPDATE pattern (with a concrete UPDATE example) and confirm a job
  appears. Align outstanding-issues #25.

Docs-only.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BHMgBiXbH4Q5tUC7WxoyaX

- Managed-alternative setup now says scope to UPDATE events only (do not tick
  INSERT) in the concrete instruction, not just a later warning — an INSERT
  webhook re-introduces the upload race.
- outstanding-issues #25: the base-URL GUC is mandatory per environment, not
  optional (the trigger no-ops without it), so the activation checklist can't
  leave the trigger inert.

Both are consistency fixes for earlier changes; neither touches the #24 row or
next-id marker (the ledger-collision surface vs #1066).

Docs-only.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BHMgBiXbH4Q5tUC7WxoyaX

- Renumber the webhook ledger rows #24-#27 -> #25-#28 (next-id 029) so they
  no longer collide with #1066's #24 (WebKit e2e). Per the consolidation
  decision, #1065 lands and the duplicate Codex webhook-doc PRs are closed;
  #1066 stays as a separate item.
- Scope the "receiver 500 -> retries" claim in the receiver-behaviour bullet:
  it only holds for a caller that actually retries, and neither documented path
  (raw net.http_post trigger or UPDATE-only managed webhook) does, so a failed
  clear can leave reindex_requested stuck true; recover via clear-then-flip.

Docs-only.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BHMgBiXbH4Q5tUC7WxoyaX

The Railway receiver forwards deploy alerts via postChatNotification, which
reads SLACK_WEBHOOK_URL/DISCORD_WEBHOOK_URL from server env; GitHub repo
secrets only feed the CI-failure workflow. Repo-secret-only left the Railway
webhook authenticated but returning forwarded:false. Clarify #25 checklist
and webhooks.md §1.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BHMgBiXbH4Q5tUC7WxoyaX

Co-authored-by: Cursor <cursoragent@cursor.com>

)